Common keywords
This section describes common keywords, applicable to multiple intersection types:
The APPROACH keyword takes a list of integers as its value. It has two functions within the junction description:
-
It begins a sequence of keywords which describe the specified approach. This sequence continues until the next occurrence of Node, Type, LaneAdjust, CentralBusinessDistrict, CycleTime, Phase, MajorRoadWidth, CentralReservationWidth, StorageSpace, FourLaneMajor, Approach1, Approach, or the end of the JUNCTION statement.
-
It describes how neighbors of the modeled node are grouped into approaches. The value of the keyword is a list of node numbers of nodes adjacent to the node being modeled. The grouping of neighboring nodes into a single approach may be necessary, for example, because CUBE Voyager can only model three- or four-legged intersections (although, at roundabouts, this restriction may be overcome by modeling the circulating section explicitly); because some of the neighbors are fictional (for example, zone centroid connectors); or because the two lanes of a road are represented by individual links.
Every node, which is a neighbor of the modeled node, must appear in exactly one Approach clause.
CUBE Voyager requires that the legs of a junction can be assigned a clockwise ordering by using the coordinates of the nodes involved. Any grouping of links into legs must not invalidate the ordering. For example, in the diagram below, a is a modeled node. Any valid approach which includes both nodes b and d must also include node c.
Every junction description must contain exactly one occurrence of the integer-valued keyword APPROACH1. Its value is the node number of a node adjacent to the modeled node, Node. The approach containing the specified node, is taken to be the first approach and the other approaches are numbered in relation to it.
By default, the approaches are numbered in anti-clockwise order, but if LEFTDRIVE = y is in force, the approaches are numbered in clockwise order.
At two-way stop-controlled and priority (two-way yield-controlled) intersections, the first and third approaches are major and the second and fourth (if any) approach are minor.
At three-legged intersections, the value of APPROACH1 determines which movements are available from each approach:
At other modeled intersections, the choice of APPROACH1 is arbitrary with no modeling consequences.
Every junction description may contain at most one occurrence of the logical-valued keyword ENABLE. If it has the value false, CUBE Voyager will ignore the entire junction description (that is, no intersection modeling will occur at the node).
ENABLE is a quick way of turning modeling on and off at a particular node from within the junction file during model development. Modeling can also be turned on and off in the CUBE Voyager Highway script file using the N clause of the FILEI JUNCTIONI command.
This real valued keyword specifies the delays, in minutes per vehicle, to be used during the first PATHLOAD command to be executed. This occurs prior to the first Adjust phase, so no calculated values will be available yet. Once an Adjust phase has been executed, calculated values will replace these initial estimates.
By default, a value of 0.0 minutes is used. However, in urban areas, this is a very poor estimate and it is very desirable that better values be supplied.
An approach’s ESTIMATEDDELAY value is analogous to a link’s initial travel time. On the assignment’s first iteration, no volumes exist yet to use for junction-delay calculations. During the first iteration, this user-specified value provides an initial estimate of the movement delay during path building.
For any "approach," EXITONLY=y indicates that the leg is not an approach; it is an exit only. No other keywords, except EXITLANES, may be coded for the approach.
The coding of EXITONLY must agree with the network (that is, the exit only approach must correspond to a set of one-way links leading away from the modeled intersection).
This keywoard signifies if the delay calculations should be based on HCM 2000 or HCM 2010. Valid values are either 2000 or 2010. Depending upon which type of delay calculations the user wishes to use, the respective value will be used. For the new calculators, it is set to 2010.
This is the number of vehicles (pcu) that are waiting to make the specified movement from the specified approach at the beginning of the model period. It defaults to zero.
INITIALQUEUE is the queue at the start of the modeled period. INITIALQUEUE generates additional delay after CUBE Voyager assigns flows and calculates delay because the vehicles arriving during the assignment must wait for the queue in front of them to discharge before they reach the stop line (or give-way line). Consequently, if there is no assignment (that is, just path building for skimming), INITIALQUEUE has no effect. Note that the initial queue’s discharge rate is not a constant; the discharge rate depends on the junction’s conflicting flows. Rather than being additional time added to the delay at the end of the process, INITIALQUEUE is more like additional demand added to the assigned demand prior to junction calculations. However, the delay to the vehicles in the initial queue is not part of the results. The results only include the delay that these initially queueing vehicles cause to the vehicles that arrive during the modeled period.
The MINIMUMCAPACITY keyword takes a positive value in vehicles per hour as its argument. It is coded by approach. If no value is coded, a default value of one vehicle per hour is applied.
If the calculated capacity for any stream from an approach is less than the minimum capacity value for that approach, the minimum capacity will be used instead of the calculated value. This substitution occurs before any delay calculations are started.
The minimum capacity is most likely to apply when a movement is very lightly trafficked but is very heavily opposed. In this circumstance, the delay for the lightly trafficked movement will be close to 60/MinimumCapacity (that is, the default value leads to delays being estimated as an hour).
The default minimum capacity of one vehicle per hour is sufficient to prevent division by zero errors from crashing program execution but there are two arguments in favor of applying a higher value:
-
Modeling expediency: If a minimum capacity of one vehicle per hour results in a predicted delay of the order of an hour, trips will be diverted away from that turn during subsequent iterations. So long as the turn has low traffic there is little reason for the turn model to allocate capacity to that movement (especially at adaptive signal models where the signal optimizer will be trying to allocate the available green time where the flow is heaviest). Thus a positive feedback may occur between having low traffic on the turn and having high delay on the turn.
-
Driver behavior: If conditions are very congested, drivers will no longer wait for an appropriate gap in the opposing stream. Eventually, they will just force their way into a smaller gap. This is especially true when the opposing stream is a slow moving queue.
The MOVEMENT keyword takes one of three case-insensitive values:
Each occurrence begins a sequence of keywords which describe the specified movement from the current approach. The sequence continues until the next occurrence of APPROACHWIDTH, AVERAGELANEWIDTH, BUSBLOCKAGE, CAPACITYINTERCEPT, CAPACITYSLOPE, ENTRYANGLE, ENTRYRADIUS, ENTRYWIDTH, EXITONLY, FLARELENGTH, GRADE, INSCRIBEDDIAMETER, MINIMUMCAPACITY, MOVEMENT, NUMBEROFLANES, PARKINGMANEUVERS, RANDOMNESS, SINGLELANE, TURNCHANNELIZED, FREEFLOWCAP, or the end of the approach.
Care should be taken when coding CRITICALGAP and FOLLOWUPTIME which can occur as keywords at both the approach and movement levels. When coding gap-acceptance roundabouts, these two keywords should appear within each approach, before any movements for that approach are described. When coding two-way stop-controlled intersections, it will not usually be necessary to code CRITICALGAP or FOLLOWUPTIME, but if they are coded they must be coded by movement.
Every junction description must contain exactly one occurrence of the integer-valued keyword NODE. Its value is the node number of the junction to be modeled.
RANDOMNESS is a real-valued keyword which specifies how random the service times are with respect to the arrival times. Its value must satisfy the inequality 0.0 < RANDOMNESS <= 1.0. At geometrically modeled signals, the platoon ratio is estimated as 2(1.0 - RANDOMNESS)
By default, RANDOMNESS is 0.55 for signalized intersections and 1.0 for unsignalized intersections. These values are appropriate for isolated junctions (that is, arrivals are random). The lower value for signals reflects that even if arrivals at a signal are random, the service times depend on whether the arrival was at a green signal aspect or a red one.
However, in urban areas where there are signal linkage effects, the appropriate RANDOMNESS values are reduced. RANDOMNESS values of 0.1 or 0.2 are appropriate for signals in advanced traffic management systems (for example, SCOOT, SCATS, OPAC) or in offline signal plans at the time that they are installed. Unsignalized intersections in this region should have RANDOMNESS values of the order 0.3 or 0.4.
Offline signal plans are generally not completely up to date so they are usually more random than ATMS. Consequently, in areas where offline signal plans operate RANDOMNESS values for signals should be 0.3 or 0.4; values of 0.6 to 0.8 are appropriate for unsignalized intersections in these areas. When using "dummy links" to model internal parts of a signal (such as modelling a five-armed signal as two nodes) synchronization across the dummy link is perfect. Therefore, code very low values of randomness, such as 0.01, for the relevant approaches.
Every junction description must contain exactly one occurrence of the keyword TYPE. It determines the type of junction to be modeled. Its value should be taken from the following list:
The keywords are case insensitive; the capitalization in the list above is merely to improve readability.
Note that the type field only distinguishes between different types of intersection on the ground. When CUBE Voyager offers more than one methodology for modeling a particular kind of junction control, other keywords will be used to distinguish between them:
-
The presence or absence of CRITICALGAP and FOLLOWUPTIME (by approach) distinguishes between gap-acceptance and empirical roundabout modeling
-
The presence or absence of MAJORROADWIDTH distinguishes whether a priority junction uses geometric modeling or measured saturation flows
-
The value of LANEADJUST distinguishes whether a fixed time signal uses geometric modeling or measured saturation flows
-
The value of HCMVERSION determines teh delay calculation methodolgy to use. (only applies to All-Way, Two-Way and Roundabouts)
The exception to the above rule is signals when there are several layers of choice of modeling methodology. When observed base- year signal settings are available, use TYPE=FixedTimeSignal to perform delay calculations for those settings. However, given a feasible signal setting and a set of constraints, CUBE Voyager can optimize the settings for the forecast flows. This facility is invoked using TYPE=AdaptiveSignal. (Note that when forecasting future years, adaptive modeling is always recommended; even if the signal controller is fixed time, some traffic engineer will reset the signals every few years.)
The next level of modeling methodology chooses between calculating capacities using supplied saturation flows or calculating them using the methodology described in HCM 2000, Chapter 16. The HCM methodology is invoked using the keyword LANEADJUST. Both methodologies may be invoked either using supplied settings or adaptive green time calculations. Note that the HCM methodology can model semi-actuated signal controllers. Giving the keyword UnitExtension to a positive value for some approach invokes this model. The issues of "adaptive settings" (that is, future or base year) and "actuated controllers" (that is, hardware in the field) are independent of each other.
When HCM capacity calculations are executed, by default CUBE Voyager also applies the HCM delay calculations. However, for all other models, a delay equation formulated by Ian Catling is used. If you code DELAYEQUATION=Catling you can force the use of Catling’s delay formulation at an HCM signals.
Note that the type of control called a "priority junction" in the U.K. (where they are very common) would be called a "two-way yield- controlled intersection" in the U.S. (where stop-controlled intersections are the norm).
U-turn control keyword specifies if the intersection has U-turn movement coded locally. It has 3 check boxes at each approach to specify if U turns are allowed or banned, and if it has an exclusive lane. If users check Allow only, it means that U-turn movement does not have an exclusive lane but shared with the left most lane with the left turn lane(s). Allow and Ban cannot be checked together. If they are both unchecked, then it means it will be controlled by the keyword set in Voyager (AllowAllUTurns). If any of the three boxes are checked, it means that this intersection node has local settings. See :PARAMETERS.
This keyword is the U turn saturation flow reduction factor value. If specified, it will override the global default setting, regardless of the turn overlap condition. The valid range for this key word is [0.01, 0.66]. The Intersection Data Editor only takes values with 2 decimal places. If provided with more than 2 decimal places, the values will be rounded up with 2 decimal places. There is a file default specified for the whole junction data file (See Data file settings) option for No Turn Overlap and With Turn Overlap condition. If not specified in the File Settings, it will default to 0.18 and 0.33 for no overlap and with overlap. The overlap condition is determined by the software automatically from the phase setting. See Methodology for U-Turns at Signalized Intersections.